Add support for RBF-ing splice transactions #2925
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Oct 10, 2024
If the latest splice transaction doesn't confirm, we allow exchanging `tx_init_rbf` and `tx_ack_rbf` to create another splice transaction to replace it. We use the same funding contribution as the previous splice. When 0-conf isn't used, we reject `splice_init` while the previous splice transaction hasn't confirmed. Our peer should either use RBF instead of creating a new splice, or they should wait for our node to receive the block that confirmed the previous transaction. This protects against chains of unconfirmed transactions. When using 0-conf, we reject `tx_init_rbf` and allow creating chains of unconfirmed splice transactions: using RBF with 0-conf can lead to one side stealing funds, which is why we prevent it. If our peer was buying liquidity but tries to cancel the purchase with an RBF attempt, we reject it: this prevents edge cases where the seller may end up adding liquidity to the channel without being paid in return.
remyers
reviewed
Oct 14, 2024
Contributor
remyers
left a comment
remyers
left a comment
There was a problem hiding this comment.
Looks good so far, I only have a few comments/questions.
...e/src/test/scala/fr/acinq/eclair/channel/states/c/WaitForDualFundingConfirmedStateSpec.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/channel/fund/InteractiveTxFunder.scala
Show resolved
Hide resolved
...e/src/test/scala/fr/acinq/eclair/channel/states/c/WaitForDualFundingConfirmedStateSpec.scala
Outdated
Show resolved
Hide resolved
As reported in the PR comments.
This adds to existing tests a simple check that alternate funding txs that won't confirm are rolled back so that their inputs will be unlocked.
remyers
approved these changes
Oct 17, 2024
Contributor
remyers
left a comment
remyers
left a comment
There was a problem hiding this comment.
I've gone over these changes now a few times and it all looks good!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the latest splice transaction doesn't confirm, we allow exchanging
tx_init_rbfandtx_ack_rbfto create another splice transaction to replace it. We use the same funding contribution as the previous splice.When 0-conf isn't used, we reject
splice_initwhile the previous splice transaction hasn't confirmed. Our peer should either use RBF instead of creating a new splice, or they should wait for our node to receive the block that confirmed the previous transaction. This protects against chains of unconfirmed transactions.When using 0-conf, we reject
tx_init_rbfand allow creating chains of unconfirmed splice transactions: using RBF with 0-conf can lead to one side stealing funds, which is why we prevent it.If our peer was buying liquidity but tries to cancel the purchase with an RBF attempt, we reject it: this prevents edge cases where the seller may end up adding liquidity to the channel without being paid in return.
Fixes #2781